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THIS  REPORT  IS  THE  THIRD  OF  A  SERIFS  WHICH 
DOCUMENT  THE  LESSONS  LEARNED  IN  THE  USE  OP  ADA  IN  A 
COMMUNICATIONS  ENVIRONMENT. 


ABSTRACT 

I  h  X  S  pap  O'  X"  Ci  X  S  C  U  S  S  C  S  5  O  t  X  W  3  r  8  8  e  '.J  ■  J  i '  i  t  g  i 1 '  i  j  ■  t .  e  K  H  t  ] 

demonstrate  how  the  Ada  programming  language  can  !>.- 
utilized  as  a  tool  to  implement  software  design 
me thodo ioy ie s  which  support  software  security. 

The  major  security  risk  in  the  military- 
te lecomm uni cat  ions  environment  is  the  compromise  ) t 
secure  or  sensitive  information  -i  r.  d  'or  n  o  t; 
delivering  a  message  or  pat  ;  it  a  moss  a  g  •••» . 
Software  security  issues  i  n  tended  t-  • ;  cl  unirmto 
these  and  other  security  risks  ore  numerous.  This 
paper  addresses  a  limited  r.umbe  r  of  i  usues  to 
i  l  lustrate  how  Ada  is  being  used  to  a ^pl  i  sK 
more  aecure  software  product.  Security  issues 
related  to  interlacing  message  data,  prevention  of 
lost  data,  message  and  command  validation,  message 
distribution  integrity,  and  information  protection 
a  re  addressed. 

The  paper  goes  into  a  description  of  now  the  SARAH 
designers  are  approach i n g  the  problem  of  designing 
tor  a  secure  environment,  < > o d  software 
engineering  practices  need  t.  a  b  >:■  a  p  p  L  i  e  d  it 
effective  software  is  to  be  developed  tor  secure 
systems.  Some  o  L  the  areas  which  neeo  to  n e 
addressed  during  the  analysis/design  phase  include 
localization,  under standee!  Lity,  reliability, 
abstraction,  confirmability,  and  modularity. 

Ada  provides  a  rich  set  of  Language  features  which 
can  be  used  to  develop  reliable,  survi.  vable  and 
secure  software  systems.  The  Ada  Language  was 
designed  to  support  the  development  of.  Large 
systems  which  would  be  developed  using  modern 
software  engineering  principles.  The  features  that 
directly  support  the  development  of  software  tor 
secure  systems  are  strong  data  typing,  packaging, 
generics,  and  exception  handling. 

Other  aspects  of  the  Ada  environment  that  must  be 
considered  in  the  security  of  the  final  product  are 
the  newness  oL  the  technology,  differences  In 
implementation  techniques  by  the  variety  of  vendors 
in  the  market,  and  new  programming  support  tools 
that  have  little  or  no  track  record  to  verity  the 
stability  of  the  product. 
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1.  INTRODUCTION 


1.1.  BACKGROUND 

Today's  world  political  and  military  sit.  a  at  1  on  i  r,  such  that 
compromise  or  interception  ot  classified  or  sensitive  military 
information  could  have  grave  c0nse.4uer.ces  tor  ou  r  rai  iota] 
security.  Stringent  methods  of  data  protection  are  t  egu  1  t**-d. 
There  are  a  number  of  ways  ot  protecting  classified  and  sensitive 
information  in  the  Automatic  Data  Processing 
(ADP) /'Telecommunications  environment  ^  : 

o  Physical  Security:  The  prevention  of  unci  e  a  r  e n 
personnel  from  gaining  ph  y  s  1  c  a  i  a  c  cess  r  o  t  h  e 
controlled  space  around  ADP/  T  e  l  e  c  o  mmunic  it  so  r.  s 
equipment  which  process  class i  t  ie.l  data. 

o  Hardware  Security:  Usually  involves  fie  use  ot  Ti.MPKSl 
approved  equipment  to  prevent  til  e  o  c  c  u  r  r  o  n  c  «  o  t 
compromising  emanations.  In  addition  to  eman  a  t  i  on.s  , 
certain  hardware  features  may  work  in  conjunction  with 
the  system  software  to  ensure  process  integrity. 

o  Cryptographic  Security:  The  process  of  encrypting  text 
before  transmission  on  uncleared  circuits  to  render  the 
information  unintelligible  to  potential  interceptors. 

o  Software  Security:  The  use  of  the  system  software  to 
implement  and  enforce  an  array  ot  security  measures 
used  to  prevent  the  compromise  of  classified.  01- 
sensitive  data  from  ADP/Telecommunicat  i  or.s  environment. 

This  paper  discusses  software  security  and  seeks  to  demonstrate 
how  the  Ada  programming  language  car.  be  utilized  as  a  tool  to 
implement  software  design  methodologies  which  support  software 
security  methods. 

This  paper  is  one  in  a  series  which  seeks  to  help  potential  Ada 
developers  gain  practical  insight  into  what  is  required  to 
successfully  develop  Ada  software.  With  this  goal  in  mind,  Air 
Staff  tasked  the  Command  and  Control  Systems  Office  (CCSO)  with 
evaluating  the  Ada  language  while  developing  reuL-time  digital 
communications  software.  CCSO  chose  the  Standard  Automated  Remote 
to  AUTODIN  (Automatic  Digital  Network)  Host  ( SARAH ) ^  project  as  a 
basis  for  this  evaluation.  SARAH  is  a  small  to  medium  size 
project  (approx.  4  0 , U 0 0  lines  ot  source  code)  which  will  function 
as  a  s tanda rd- 1 n te 1 1 igen t  terminal  for  AUTODIN  users  and  will  be 
used  to  help  eliminate  punched  cards  as  a  transmit /receive 
medium.  The  development  environment  for  SARAH  consists  of  the 
SotTech  Ada  Language  System  lALS)  hosted  on  a  Digital  Hguipment 
Corporation  VAX  11/780,  a  Burroughs  XESSO  Megaframe  and  several 
IBM  compatible  PC-XT  and  PC -AT  microcomputers.  The  *  r  c  it  ‘-he 
focal  point-,  r.  f  c:,  1  s  integrated  development  environment.  The 
source  code  developed  on  the  XE550  and  microcomputer  workstations 
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is  maintained  by  the  ALS  configuration  control  system.  in 
addition,  reusable  modules  are  baselined  by  the  ALS  and 
maintained  on  the  VAX  in  a  software  repository. 


1.2.  PURPOSE 

The  purpose  of  this  paper  is  to: 

o  Outline  Automatic  Data  Processing  (ADP)  security 
risks  which  may  be  managed  through  the  software 
implementat ions . 

o  Identify  software  application  and  design  methods  whicn 
can  be  utilized  to  support  software  oriented  risk 
management . 

o  Identity  Ada  language  features  and  characteristics 
which  support  these  design  methodologies. 

o  Caution  the  implementor  about  unknowns  of  the  language 
and  other  considerations  as  they  pertain  to  security. 


1.3.  SCOPE  AND  CONSTRAINTS 

The  scope  of  this  paper  is  limited  to  those  security  requirements 
applicable  to  the  SARAH  system.  SARAH,  as  a  General  Service 
(GENSER)  system,  is  not  subject  to  as  many  security  requirements 
as  the  Defense  Special  Security  Communications  System  (DSSCS)^. 
Since  SARAH  will  be  a  telecommunications  system,  security  risks 
discussed  are  those  of  concern  to  developers  and  implementors  of 
telecommunications  systems  and  may  not  be  applicable  to  ADP 
systems.  The  security  risks  discussed  are  not  intended  to  be 
comprehensive,  even  for  a  telecommunications  system,  but  were 
selected  as  issues  of  high  concern  to  telecommunications  systems 
and  as  good  examples  for  demonstrating  the  potential  of  the  Ada 
language  to  support  software  security  design  methods. 

Since  the  authors  of  this  paper  are  currently  involved  in  the 
design  phase  of  the  SARAH  Ada  development  project,  they  are  not 
in  a  position  to  advise  about  Ada  security  applications  from 
personal  experience.  They  have  followed  the  development  of  the 
Language,  have  studied  the  language  extensively,  and  have  a  good 
deal  of  software  development  experience  with  military- 
telecommunications  systems  using  a  variety  of  languages  and 
development  methodologies. 
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2.  SECURITY  ISSUES 


In  the  military  telecommunications  er.v  i  ronment  ,  t  tie  over  Lying 
security  risk  is  the  compLomise  ot  sensitive  or  classified 
information  and/or  not  delivering  a  message  or  part  of  a  message. 
With  this  in  mind,  we  will  discuss  the  following  security  issues: 
prevention  of  interlacing  of  message  data,  prevention  of  lost 
data,  message  and  command  validation,  message  distribut  ion 
integrity,  and  information  protection.  The  SARAH  workstation 
will  provide  a  secure  communications  environment  for  the 
creation,  transmission,  reception,  and  delivery  of  messages 
within  the  Defense  Communications  Agency  (  DC  A )  AUTODIN  system. 
Issues  addressed  are  in  the  context  of  the  application  for  the 
SARAH  workstation. 

In  this  section  we  will  look  at  some  general  sec  u  r  i  t  y  issues.  i  n 
Later  sections  we  will  look  at  both  design  issues  and  the  Ada 
language  to  see  their  relation  to  security. 


2.1.  PREVENTION  OF  INTERLACING  MESSAGE  DATA 

Message  interlacing  occurs  when  part  or  ali  of  one  message 
becomes  mixed  with  another  message.  When  this  occurs,  the 
interlaced  message  content  may  be  of  greater  classification  than 
the  classification  specified  in  the  message  header.  This 
message  may  or  may  not  also  be  delivered  normally,  depending  on 
what  caused  it  to  become  interlaced  with  the  other  message. 
Messages  are  split  into  blocks  at  various  points  during 
transmission  to  facilitate  efficient  handling.  The  system 
handles  any  number  ot  messages  at  one  time  and  must  maintain  each 
as  an  entity.  Each  message  entering  the  network  contains  a 
message  header  which  consists  ot  a  number  ot  information  fields. 
The  classification  field  is  used  to  prevent  a  security 
compromise.  Other  fields  within  the  header  and  trailer  are  used 
to  check  for  proper  length  and  ending  block  information. 


2.2.  PREVENTION  OF  LOST  DATA 

Lost  data  results  in  message  data  not  being  delivered  as 
intended.  To  prevent  this,  the  SARAH  sot  twine  must  maintain 
system  integrity  (integrity,  as  used  in  this  paper,  means  that 
independent  components  or  entities  remain  independent  and 
complete)  and  data  flow  integrity  at  a  1  l  time's. 

One  way  to  prevent  lost  data  is  to  ensure  all  information  entered 
into  the  SARAH  terminal,  both  control  information  and  message 
information  must  be  validated,  usable,  and  appropriately  handled. 
Any  introduction  ot  information  that  is  subsequent  [y  never  used 
or  inaccessible  is  unwarranted  and  should  be  prevented. 

Another  thing  that  must  be  done  is  to  ensure  the  message  traffic 
is  properly  queued.  Improper  queuinj  of  messages  for  delivery- 
through  the  system  can  result  in  either  lost  messages 


(undelivered)  or  mis  routed  (delivery  to  the  wrong  customer). 
Either  case  must,  be  prevented. 


To  prevent  data  from  being  lost,  the  distribution  process  must 
cover  all  contingencies.  Initialization  of  the  output  routing 
matrix  must  result  in  specific  instructions  for  handling  a 
message  whose  address  does  not  match  any  of  the  entries  in  the 
matrix.  Since  any  work  station  can  serve  as  a  backup  for  another 
while  receiving  its  own  traffic  load,  this  default  queue  logic 
must  be  available. 

The  final  ingredient  in  preventing  lost  data  is  to  maintain 
appropriate  and  sufficient  information  about  messages  being 
processed.  This  will  allow  recovery  of  all  undelivered  traffic 
after  a  failure  of  the  system.  The  SARAH  system  will  satisfy 
this  requirement  with  a  printed  journal  and  various  techniques 
for  recovery  from  floppy  disks  and  the  host  computer  system. 
These  steps  will  ensure  no  messages  are  lost  during  the  recovery 
process . 


2.3.  VALIDATION 

2.3.1.  COMMAND  VALIDATION 

The  system  menu  function  takes  commands  from  the  keyboard  and 
directs  the  command  selections  to  the  other  system  functional 
units  (or  modules)  of  the  system.  Each  incoming  command  is 
validated  by  the  menu  function  to  ensure  the  command  is  a  member 
of  a  limited  set  of  commands  allowed  for  each  of  the  other  system 
functional  units. 


2.3.2.  MESSAGE  VALIDATION 

Before  entry  into  the  AUTODIN  network,  the  message  will  be 
validated  by  the  message  preparation  module  of  the  SARAH  system. 
This  validation  will  check  the  contents  of  the  message,  keying  on 
the  message  header,  to  ensure  that  it  meets  all  the  criteria  for 
proper  routing  in  the  AUTODIN  network.  Checking  is  done  on 
precedence  c 1 a s s i f i ca t ion ,  content  indicator  code,  date-time- 
group,  originating  station  routing  indicator,  station  serial 
number,  and  routing  indicator  codes.  If  an  error  is  detected, 
the  message  will  not  be  allowed  to  be  stored  on  the  message 
transmission  disk.  The  operator  will  be  notified  so  the  message 
can  be  changed  to  the  proper  format  for  transmission. 


2.4.  DISTRIBUTION  INTEGRITY 

SARAH  workstations  wiLl  ensure  that  messages  are  delivered  to  the 
proper  addressee  by  validating  message  header  information 
against  an  output  routing  matrix.  The  SARAH  system  will  provide 
a  facility  to  create  the  customer  output  routing  matrix. 
The  matrix  wilL  be  created  on  site  at  installation  time  and  may 
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be  modi  tied  as  re -4  ui  red.  it  will  provide  a  LI  necessary 
information  to  validate  each  message  tie  fore  delivery  to  the 
customer.  Validation  criteria  will  include  classification 
identification,  routing  indicator  code,  distribution  media 
(printed  anu/'cr  floppy  disk),  etc. 


2.5.  INFORMATION  PROTECTION 

Information  protection,  in  this  context  ,  is  trie  isolation  of 
system  data  bases  (both  the  information  in  and  the  processing 
logic  of  the  data  bases)  from  unexpected  effects  of  messages 
being  processed  or  other  dynamic  data.  One  area  if  concern  is  the 
message  queuing  systems  which  control  the  order  of  delivery  of 
messages  being  transmitted,  received,  or  being  prepared  for 
distribution.  These  queues  may  have  to  interact,  with  a  system 
data  base  (i.e.  customer  distribution  matrix)  but  not  be  allowed 
to  affect  the  data  base.  T  h  e  system  must  be  equipped  with 
appropriate  safeguards  to  ensure  information  protection.  As  we 
will  see  later,  the  Ada  language  has  some  features  that  will  help 
us . 


3.  DESIGN  FOR  SECURITY 


As  the  size  and  complexity  of  software  systems  increases,  so  does 
the  probability  ot  error.  For  secure  systems,  errors  in  coding 
or  design  could  have  disastrous  effects  on  national  security. 
Good  software  engineering  practices  need  to  be  applied  if 
effective  software  is  to  be  developed  for  secure  systems.  Some 
ot  the  areas  which  need  to  be  addressed  during  the 
an  a  1 y  s i s / design  phase  include  abstraction,  modularity, 
localization,  ur.de rstar.dab i  1  ity,  confirmability,  and  reliability. 

We  will  now  take  a  look  at  several  design  issues  that  can  impact 
security.  We  will  not  specifically  look  at  the  Ada  language 
until  the  next  section  ot  the  report. 


3.1.  ABSTRACTION 

Abstraction  should  be  used  when  designing  secure  systems  so  that 
security  issues  are  not  clouded  by  less  relevant  details. 
Abstraction  is  one  of  the  fundamental  tools  for  controlling 
complexity^1  We  use  -abstraction  in  our  lives  every  day  to 
control  complexity;  the  principles  ot  abstraction  for  software 
engineering  are  r.o  different.  For  example,  when  we  look  at  a 
computer  system,  we  see  the  visual  display,  keyboard,  processor 
and  storage  devices.  In  effect,  we  have  abstacted  our  view  of 
the  computer.  We  know  that  the  processor  is  made  up  of  integrated 
circuits,  decoupling  capacitors  etc.;  however,  thote  aspects  are 
not  relevant  to  our  top  level  view  and  if  introduced  would  creat" 
an  unnecessary  amount  of  complexity.  Perhaps  so  much  so  that  we 
would  forget  about  the  functionality  ot  the  major  components. 

The  principle  of  abstraction  is  being  extensively  used  for  the 
SARAH  software  system.  Figure  3.1  shows  the  top  level 
abstraction  view  of  the  SARAH  software.  At  this  level,  the 
SARAH  designers  knew  that  several  requirements  needed  to  be 
incorporated  into  the  system.  For  example,  connection  to  the 
Defense  Communications  System  was  a  requirement,  and  so  a 
subsystem  that  handled  communications  (Comm)  was  needed.  At  this 
level  ot  abstraction,  the  designers  knew  that  other  elements  ot 
the  system  were  also  needed  such  as  a  message  edit/preparation 
facility  and  an  1  nput/output  (I/O)  system. 

At  this  level  of  abstraction,  high  level  system  interfaces  and 
overall  system  functionality  can  be  defined.  Working  at  such  a 
high  level  of  abstraction,  the  designers  have  been  able  to 
address  high  level  security  issues.  For  example,  the  Comm  system 
will  operate  independently  of  the  Edit  system  and  not  rely  on 
other  systems  to  maintain  queues  or  manage  the  incoming  or 
outgoing  messages. 
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Mam  Menu  Information 


SARAH  Top  *-*»«!  Topographical  Chart 


One  ot  tne  major  •;.*  ;  :  v  i  t  y  roqu  i  remc-nts  for  the  SARAH  system  is 
that  the  t  r  a  r.  m  i  i  and  :o  i  ve  data  must  not  he  interlaced.  As 
such,  when,  the  next  i  -  L  ■■  abstraction  vas  detined  lor  the  Comm 
system,  two  so  pa  r  1 1  e  t  •  d  1  p.  io pendent  modules  were  identified. 
Usm  j  success  Le-*  lev  T-;  :• :  abstract  ion,  the  SARAH  designers  have 

he  on  able  to  cent.  rod  •  :lt*  com  p !  ex  i  ty  of  the  sysiorn  and  focus  on 
tae  security  asp'O  s  r-.  ;  a  t  i  v-i  t.o  the  level  being  defined. 

L'o  consider  a  L  i  aspects  o  i  security  at  one  level  can  create  a 
situation  where  some  aspects  ot  security  may  be  overlooked.  The 
control  ot  complexify  is  extremely  important  for  the  development 
ot  software  tor  eon?  .y  stems.  As  shown,  the  application  of 
abstract  l  nr.  to  sor  f  w  are  :e.j  i  jr.  car.  help  control  this  complex  i  ty 
a  n  c,  help  i  near go:  a  f  .•  •  c:t/  requirements  into  the  resulting 

so  t  twa re . 

Another  sot  t  ware  er.g  :  nee  r  i  ng  pr  tuciple  that  goes  "hand-in-hand" 
with  abstraction  is  i  nr-  >t  mat  ion  hiding.  Whereas  abstraction  is 
used  to  extract  t  ■  e:  t  n  t  o  c:;at  ion  at  n  particular  level  in  a 

design,  inform,  a;  i  >r.  h  i  i  r  g  makes  certain,  functions  and  data 
in  access  i  Die  r  •  >  ■.•Is"  1  c  the  design  which  do  not  need  them. 

T  he  Hierar  c  h  i  c  a  1  ;  i  e  w  .  f  s  1%  R  A  H  1  s  t  <  i  p  a  n  s  tract  i  o  r.  level  (Figure 

3.2)  p  r  o  v  i  d  e  s  a  ;  rood  e  x  a  :n  p  L  e  ot  this  sot  tware  engineeri  n  g 
feature.  For  example ,  the  start  up  module  ot  the  Comm  System  is 
visible  to  the  Main  ;or.f  to  1  Lor;  however,  the  Transmit  ant  Receive 
tasks  are  not.  As  such ,  the  Main  controller  cannot  use  any  of 
tne  f  up.c  t:  ions  ot.  dati  v  i  it  in  tne  transmit  or  receive  tasks. 
Similarly,  although  Prist  Mgr  is  visible  to  Comm,  the  converse  is 
no  t  true  and  so  Print.  Mjr  o  an  not  use  or  man  i  uu  late  any  of  the 
Comm  data  or  function:-.  Information  hiding  is  therefore  a  very 
powerful  mechanism  lot  protecting  data  within  secure  systems. 


3.2.  MODULARITY 

A  major  requirement  l  r  software  system  design  is  modularity. 
Modularity  deals  with  the  decomposition  of  a  system  into  a  number 
of  constituent  part..--,  whies  ire  interfaced  together.  Modularity 
is  a  tur.damenta  l  t  >o  l  tor  helping  us  manage  the  complexity  of 
software  systems.  A  ;  avouLar  design  will  purposely  reflect 
the  real,  world  pro!;  ;  cm  space.  The  modules  that  come  out  of  chi.; 
type  ot  design  a  re  .usual  l  y  writ  en  separately  and  later  joined  to 
form  the  program. 

IdeaLiy,  the  modufes  should  exhibit  loose  coupling.  This  can  oe 
achieved  by  keeping  the  module  interfaces  to  a  minimum  and 
collecting  or  localizing  like  data  and  functions.  Software 
'develop'd  for  secede  s/stems  should  be  modular  and  the  modules 
should  hr'-:  Loo  c  coupling  no  programmer  induced  errors  can  be 
l  oca  l  l  zed  ,  and  comp  l  ex  i  ty  car.  be  controlled. 

A  software  system  that  has  well  detined  interfaces  between 
modules  will  reduce  t  he  possibility  of  programmer  induced  errors 
curing  me  i  ntenanc--.  11  ciuplir,  is  high,  a  change  to  one  module 

H 


could  inadvertently  change  the  function  of  another  module.  Ever, 
worse,  the  system  data  may  be  unknowingly  modified  and  so  cause  a 
security  compromise.  The  Ada  language  provides  reu<_ures  which 
aid  in  making  software  transportable.  As  such,  software  systems 
developed  with  Ada  could  be  in  service  tor  quite  i  long  period  of 
time  (perhaps  in  excess  of  20  years).  Having  modules  that  are 
long  lived  means  that  the  modules  are  well  tried  and  proven. 
Well  defined  modules  which  exhibit  low  coupling  can  effectively 
reduce  maintenance  problems  and  so  help  maintain  system  integrity 
throughout  the  life  of  the  software. 


3.3.  LOCALIZATION 

Localization  dea  Ls  with  tne  proximity  of  Like  entities.  A  module 
that  has  strong  cohesion  will  be  very  local  i/.ed  because  it  will 
encapsulate  like  functions  and  data.  For  example,  the  Display 
Tools  Package  in  Figure  3.2  exhibits  a  nigh  degree  of 
localization.  The  package  contains  a  number  of  tools  for 
outputting  Display  Data  to  the  screen.  The  only  operations  that 
can  be  performed  on  display  data  are  those  provided  by  the 
package  . 

For  a  secure  software  system,  localization,  is  extremely 
important.  In  the  SARAH  system,  distribution  integrity  and 
message  interlacing  are  major  security  concerns.  Localization 
can  provide  the  basis  tor  eliminating  these  security  risks.  By 
Localizing  data  and  tunctions  to  specific  modules  or  packages 
(we'll  see  how  Ada  can  help  us  do  this,  later),  we  can  prevent 
inadvertent  data  modification  or  manipulation.  For  example, 
Received  Message  Data  and  Transmit  Message  Data  cannot  be 
intermixed  because  they  are  of  different  data  types  encapsulated 
in  separate  modules  which  have  their  own  controls  for  data 
manipulation. 


3.4.  UNDERSTANDAB I LITY  AND  CONFIRMABILITY 

It  a  software  system  is  not  understandable,  the  possibility  of  a 
security  compromise  could  be  high,  ijnderstandab i  1  i ty  relates  not 
only  to  the  resulting  code,  but  also  to  the  overall  design.  For 
example,  it  the  software  solution  does  neat  reflect,  the  real  world 
problem,  the  design  could  appear  excessively  complex  tea 
maintenance  personnel.  The  maintainer  may  therefore  make  a 
change  to  the  system  without  fully  knowing  the  eaverall  effects  of 
the  change. 

At  the  code  level,  a  detined  coding  style  should  be  used  so  that 
the  software  is  readable  and  therefore  understandable.  The  low 
level  design/implementation  standard  should  Lie  well  detined  prior 
to  development.  For  the  SARAH  project,  this  standard  is  based  on 
a  style  guide  published  by  Intel  1  iraac  Inc.1’  and  is  included  in 
the  SARAH  Software  Standards  and  Procedures  Manual  (SSPM)  as 
required  by  the  DOD-STD-2 167 ,  the  documentation  standard  for  the 
project . 
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A  defined  style  has  a  number  ot  positive  et  tacts  or:  the  ability 
o£  sot t ware  to  reliably  process  sensitive  information.  First,  if 
the  software  is  understandable,  then  functionality  is  more  easily 
validated  and  confirmed  during  walkthroughs  and  reviews.  Second, 
a  defined  structure  and  style  promotes  completeness.  For 
example,  it  the  SSPM  requires  that  all  types,  exceptions,  and 
objects  are  to  be  commented,  the  programmer  is  forced  to  consider 
the  declarations  more  carefully.  In  addition,  the  maintenance 
programmer  will  have  the  benetit  ot  these  comments  when  the 
software  is  in  its  maintenance  phase. 


3.5.  RELIABILITY 

Reliability  ot  software  tor  secure  system',  is  of  utmost 
importance.  An  unreliable  system  w  h  1  e  i »  Lj  i  < > e  e  s  s> e  s  secure 
information  could  have  drastic  effects  on  national  security.  For 
example,  if  under  certain  conditions,  a  message  system  allowed 
classified  messages  to  go  to  an  unclassified  local  delivery 
point,  a  serious  compromise  would  occur.  One  ot  the  major  design 
goals  ot  the  SARAH  development  has  been  reliability. 

Reliability  cannot  be  added  on  after  the  system  has  been 
developed;  rather,  it  must  be  designed  into  the  system.  Risk 
analysis  should  be  completed  at  each  design  abstraction  so  that 
possible  problems  are  not  overlooked.  Unfortunately,  the  most 
popular  software  Lifecycle  models  (e.g.  Waterfall  Model  )  are  not 
risk  driven  and  so  do  not  provide  a  formalized  basis  for  risk 
analysis.  To  overcome  this  deficiency,  the  SARAH  designers 
decided  to  borrow  heavily  from  the  Spiral  Model  6  an(j  introduce 
risk  analysis  at  the  completion  ot  each  design  cycle. 


4.  USE  OF  ADA  LANGUAGE  FEATURES 


Ada  provides  a  rich  set  or  language  teatures  which  can  be  used  to 
develop  reliable,  s,.rv  ivab  Le  and  secure  software  systems.  These 
features  direct)/  support  the  modern  software  engineering 
principles  discussed,  in  tne  previous  section.  This  is  not 
surprising  since  Ada  was  designed  to  support  the  development  of 
larye  systems  which  would  be  developed  using  these  engineering 
principles,  some  o t  1  he  Ada  features  that  directly  support  the 
development  of  soft,  warn:  tor  secure  systems  are  strong  data 
typing,  packaging,  ger.er  i  .:s,  and  exception  handling. 

4.1.  STRONG  DATA  TYPING 

Ada  is  a  v  e  r  y  s  t  r  o  r.  g  1  y  typed  language.  Strong  data  typing 
provides  the  basis  tor  protecting  data  objects  within  the  system. 
Some  of  the  types  that  can  ne  used  to  produce  ettective  secure 
software  include  private  typos,  enumeration  types,  and  access 
types.  In  addition,  Ada  provides  the  programmers  with  the 
ability  to  define  their  own  typos.  These  user  defined  types  can 
be  extremely  ettective  tor  the  development  or  secure  systems. 

One  of  the  security  issues  being  addressed  in  SARAH  is  message 
validation.  Ada  provides  powerful  typing  features  which  help 
accomplish  message  validation.  For  example,  by  using  user 
defined  types  together  with  enumeration  types,  the  programmer  can 
strictly  define  the  scope  of  a  particular  object.  When  the 
message  header  is  v  a  1  i  d  a  t  e  d ,  only  certain  security 
classifications  will  be  allowed.  In  the  header,  only  the  first 
letter  of  the  classification  is  provided.  For  example,  Top  Secret 
is  identified  as  "I".  A  typical  Ada  type  declaration  for 
security  classifications  is: 

type  CLASSIFICATIONS  is  (T,  S,  C,  R,  E,  U); 

Suppose  we  want  to  validate  the  message  headers  for  correct 
security,  then  we  need  to  create  an  object  of  this  type  to  which 
we  can  then  make  a  s  s  i  j  n  m  *;•  nts.  This  can  be  done  as  follows: 

Header_Secur i ty  :  CLASSIFICATIONS; 

If,  during  execution,  a  character  is  assigned  to  Header_Security 
from  the  incoming  message,  and  it  is  not  in  the  range  specified 
by  the  user  defined,  type  (CLASSIFICATIONS),  then  Ada  will  flag 
this  as  an  exception  condition  and  the  software  can  take  the 
appropriate  measures  to  handle  this  problem. 

The  use  of  enumeration  and  user  defined  types  are  also  very 
effective  for  validating  user  input  commands.  A  type  can  be 
defined  so  that  only  a  1  united  range  of  input  will  be  accepted. 
Security  is  improved  because  the  resulting  software  is  more 
understandable  and  reliable. 


4.1.1.  Private  Types 


Anotner  Ada  typing  feature  wh\ch  can  help  in  producing  secure 
software  systems  is  private  types.  Private  types  are  very 
powerful  for  protecting  data.  It  a  private  type  is  declared  in 
an  Ada  package,  then  the  only  operations  that  can  be  performed  on 
objects  of  that  type  outside  its  package  are  oqua  1  ity  ,/ir.equa  1  i  ty 
tests,  assignment,  and  any  operations  declared  in  the  package 
specification.  It  even  more  protection  is  required,  a  limited 
private  type  can  be  used  which  restricts  the  package  user  to  only 
those  operations  shown  in  the  package  spec i t icat ion.  For  limited 
private,  even  tests  for  equal i ty/i nequa 1 i ty  and  assignment  are 
not  permitted. 

In  the  SARAH  system,  Transm i t_Data  and  Rece i ved_Data  are  limited 
private  types  encapsulated  in  separate  packages.  It  another 
package  needs  to  access  this  data,  tor  example  a  validation 
package,  then  the  only  operations  that  can  be  performed  are  those 
listed  in  the  package  specifications.  The  validation  package  can 
look  at  certain  aspects  of  the  incoming  message;  however,  it 
cannot  manipulate  or  make  a  copy  of  the  data.  Visibility 
between  packages  is  controlled  and  this  further  reduces  the 
possibility  ot  unlawful  access  of  secure  data.  For  example,  the 
receive  and  transmit  packages  are  completely  independent  and  are 
not  visible  to  one  another.  As  such,  there  is  no  possibility  of 
mixing  (or  interlacing)  Rece i ved_Data  with  Transm i t_Data.  As 
shown,  private  types  are  a  very  powerful  mechanism  tor  protecting 
and  restricting  access  to  secure  data  within  a  software  system. 


4.1.2.  Access  Types 

Access  types  provide  a  powerful  mechanism  for  creating  secure 
dynamic  lists  and  queues.  Queuing  in  communications  systems  is 
an  important  function.  Queue  implementation  using  older 
languages  and  assembly  languages  is  a  complex  problem, 
particularly  when  there  are  a  large  number  of  transmit  and 
receive  lines.  As  such  th°  possibility  of  misrouting  information 
is  increased.  Access  types  provide  a  well  defined  mechanism  for 
implementing  queues,  and  so  the  resulting  implementation  is  more 
readable  and  understandable.  The  software  can  therefore  be  more 
easily  verified,  and  so  reduce  the  risk  of  a  possible  compromise 
situation. 

Since  access  types  can  be  made  private  or  limited  private,  the 
benefits  of  data  protection  are  also  available  to  the  designer.  A 
standard  queue  type  can  be  defined  and  several  independent 
objects  of  this  type  can  be  created.  For  example,  in  a  Receive 
package,  a  queue  may  be  required  for  each  local  delivery  point. 
Each  of  these  delivery  points  could  be  objects  of  the  queue  type. 
If  the  queue  type  is  made  private,  the  actual  data  structure  is 
hidden  from  the  user.  In  addition,  if  limited  private  is  used, 
the  only  operations  that  can  be  performed  on  the  queue  objects 
are  those  specified  in  the  visible  part  of  the  encapsulating 
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package.  In  summary,  access  types  provide  a  mechanism  for  easily 
defining  queues  and  lists. 

4.2.  PACKAGING 

One  of  the  unique  features  of  Ada  is  the  package.  An  Ada  package 
is  made  up  of  a  visible  part,  and  a  body.  The  visible  part 
contains  the  package  specifications  and  shows  which  entities  can 
be  exported.  For  example,  a  package  specification  for  a  package 
of  display  tools  may  tell  the  user  that  the  operations  which  can 
be  performed  on  D i sp lay_Data  are  Open  Window,  Close_Window  etc.; 
but  the  details  ot  how  this  is  done  is  hidden  in  the  package 
body.  As  such,  packages  provide  a  powerful  method  ot 
implementing  abstraction  and  information  hiding.  As  discussed 
earlier,  these  are  extremely  important  concepts  for  the  design  of 
secure  software. 

Packaging  concepts  are  being  used  extensively  in  the  SARAH 
project  for  controlling  complexity,  protecting  data,  promoting 
understandabiLity  and  enhancing  reliability.  Figure  3.2  shows 
how  the  SARAH  software  has  been  packaged.  Each  of  the  major 
functional  modules  are  implemented  as  packages.  These  pacxages 
have  defined  interfaces  to  ot. her  packages.  In  addition,  the 
package  dependencies  are  clearly  shown.  By  packaging  for  low 
coupling  and  high  module  cohesion,  package  dependencies  are 
minor.  For  a  secure  system,  this  is  important  because  if  a 
problem  arises  in  one  module,  the  effect  on  other  modules  will  be 
neg 1 ig ib le  . 


4.3.  GENERICS 

Generics  provide  a  number  of  desirable  benefits  for  secure 
software  implementations.  Generics  are  templates  of  Ada  program 
elements.  For  example,  several  instances  of  a  generic  package 
can  be  made  by  simply  instantiating  (or  filling-in)  with 
difterent  data  types.  In  SARAH,  a  Variable  List  package  is  being 
created  to  provide  a  mechanism  for  queuing  and  list  processing. 
The  package  will  be  written  just  one  time  and  then  be 
instantiated  tor  the  various  other  data  types.  For  example,  a 
queue  will  be  created  tor  Rece i ved_Headers  and  Transm it_Headers. 
In  addition,  the  same  package  will  provide  variable  list 
facilities  for  the  text  processing  section  ot  the  system.  The 
productivity  benefits  of  generics  are  substantial;  however, 
generics  also  have  a  positive  ettect  on  system  reliability, 
modularity,  and  understar.dabi  1 1  ty. 

As  mentioned  earlier,  queuing  software  for  older  communications 
software  is  complex,  and  not  very  understandable  to  the 
inexperienced.  By  using  generics,  we  wiil  reduce  the  complexity 
considerably  because  there  will  be  only  one  major  functional 
module  and  this  one  piece  ot  code  wiil  be  instantiated  to  provide 
functionality  for  severs!  independent  objects.  In  essence,  a 
package  will  be  created  for  each  data  object.  The  resulting 
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software  will  therefore  be  more  modular  to  help  enhance 
understa ndability.  The  verification  process  for  SARAH  will  be 
considerably  easier  and  more  complete  because  of  generics. 

Software  reuse  has  a  direct  effect  on  reliability  and  can  aid  in 
reducing  the  risk  of  compromise  in  secure  systems.  Generics 
provide  an  excellent  method  for  software  reuse.  Reliability  is 
enhanced  through  the  use  of  generics  because  a  previously 
verified  module  is  less  likely  to  contain  programming  errors. 
Indeed,  even  with  older  languages  such  as  FORTRAN,  where 
mathematics  libraries  were  extensively  reused,  few  errors 
resulted  from  tie  reused  code. 


4.4.  EXCEPTION  HANDLING 

Ada  provides  a  feature  called  exception  handling  to  catch  errors 
during  program  execution.  This  feature  is  easy  to  use  and  makes 
the  resulting  software  very  readable,  reliable,  and  survivable. 
As  such,  exception  handling  is  an  important  concept  for  the 
design  and  implementation  of  secure  software.  Extensive  use 
should  be  made  of  exception  handling  to  reduce  the  possibility  of 
a  security  compromise  caused  by  unreliable  software  or  hardware. 

As  previously  indicated,  reliability  must  be  built  into  the 
system  from  the  outset.  When  analyzing  and  designing  each  level 
of  abstraction,  the  designers  should  identify  and  record 
exception  conditions  which  could  possibly  create  security 
problems.  In  particular,  these  conditions  should  be  identified 
when  risk  analysis  is  performed  following  the  completion  of  a 
design  abstraction  level.  These  exception  conditions  can  then  be 
accounted  for  by  Ada  exception  handlers. 
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5.  FURTHER  CONSIDERATIONS 


Ada  is  opening  a  whole  realm  ot  possibilities  for  improved 
software  systems  dove  1  Dp:n>.*  r.  t. .  Caution  must  be  exercised, 
however,  when  entering  this  new  domain.  There  are  negative 
aspects  of  software  development  using  Ada  that  any  new  developer 
should  be  aware  ot  and  be  prepared  to  address.  The  "catch-22"  is 
basically  the  newness  of  t  he  J  .ir.guage  and  the  proliferation  ot 
compilers  and  Ada  accessories  available  on  the  commercial  market. 
Unknown  problems  may  lie  within  the  tens  of  thousands  of  lines  of 
code  comprising  the  compilers  from  each  vendor.  These  problems, 
undetected  through  the  validation  procedure,  are  there  and  will 
have  to  be  add  r e s s e d  r  a  n  ” a s  occurs"  basis.  Due  to  the 
diversity  of  the  compiler;  designers  in  the  Ada  world,  solutions 
to  the  same  problems  in  language  implementation  take  on  different 
designs.  This  difference  in  understanding  and  solution  processes 
makes  for  unknown  numbers  ot  future  problems.  Effects  of  this  on 
the  concepts  ot  data  hyping,  module  isolation,  limited  access, 
etc.  are  risks  that  have  to  ne  taken  and  faced  when  and  if 
problems  do  surface. 

Another  area  ot  risk  t.h«  t  should  be  highlighted  is  that  of  the 
support  environment  that  is  available  with  the  Ada  compilers 
being  acquired  today.  The  Ada  Programming  Support  Environment 
(APSE)  is  a  set  of.  development  tools  that  can  assist  and  provide 
added  control  over  the  software  being  developed.  Some  vendors 
are  marketing  support  environments  that  come  from  existing 
product  lines  and  are  proven.  Tools  such  as  Ada  syntax  checkers, 
debuggers,  stub  generators,  code  generators,  etc.  are  available 
and  being  billed  as  wonder tu 1.  Care  must  be  taken  to  ensure  the 
proper  function  ot  such  tools.  The  assumption  that  the  resultant 
code  is  pure  and  secure  should  not  be  made.  Vigilance  is 
necessary  in  this  emerging  Ada  world  of  technology  and  we  must  be 
the  front  line  ir.  preventing  the  occurrence  ot  problems. 


6.  SUMMARY  AND  RECOMMENDATIONS 


6.1.  SUMMARY 

Modern  software  engineering  techniques  and  specific  features  of 
the  Ada  language  provide  very  useful  tools  for  use  in  developing 
secure  ADP  and  telecommunications  systems.  The  most  dangerous 
risk  to  these  systems  is  the  compromise  of  classified  or 
sensitive  iniormation  and  the  loss  of  important  information. 

The  SARAH  workstation  project,  as  a  telecommunications  terminal, 
must  address  a  number  of  security  issues;  among  them  are  the 
prevention  of  interlacing  of  message  data,  the  prevention  of  lost 
message  data,  system  command  and  message  validation,  distribution 
integrity,  and  information  protection. 

The  major  software  design  methodologies  useful  for  handling  these 
issues  are  abstraction,  modularity,  and  localization. 
Abstraction  allows  the  designer  to  concentrate  his/her  efforts 
on  a  particular  problem.  Modularity  and  localization  allow  the 
system  functions  to  be  logically  grouped  and  provides  for  more 
easily  controlled  interfaces. 

These  methodologies  also  seek  to  achieve  the  goal  or 
understandabi 1 ity,  verifiability,  and  reliability.  Reliability 
is  greatly  increased  by  designing  a  verifiable  system  which  can 
be  completely  and  easily  tested.  Systems  must  be  understandable, 
both  at  the  design  level  and  at  the  code  level.  Understandabi  1 i ty 
builds  reliability  into  the  system;  it  also  helps  to  ensure  that 
the  system  will  continue  to  be  reliable  after  maintenance. 
Maintenance  programmers  need  an  understandable  system  to  help 
them  locate  problems,  correct  problems,  and  predict  the  effect  of 
modifications  to  the  system. 

Ada  provides  features  that  support  modern  design  methodologies 
and  thus  software  security.  Strong  data  typing  and  exception 
handling  helps  to  ensure  the  system  will  function  reliably  and 
predictably  when  subjected  to  many  different  input  conditions. 
Packaging  is  one  of  Ada's  most  useful  features;  it  provides  an 
efficient  mechanism  for  modularization,  localization, 
abstraction,  modifiability,  and  unders tandab i 1 i ty . 

Caution  should  be  exercised  because  of  compiler  and  support 
environment  unknowns.  Ada  is  a  large  language  and  various 
commercial  compilers  implement  the  language  features  in  many 
different  ways.  Ada  has  arrived  with  many  support  environment 
tools  whose  efficiency  and  predictability  may  vary. 


6.2.  RECOMMENDATIONS 

o  Become  aware  of  modern  software  engineering  principles 
and  prepare  to  enforce  their  application  to  all  aspects 
of  software  development. 
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o  Use  the  principles  ot  abstraction  extensively  in  the 
area  of  localization  and  data  typing  to  ensure  a  more 
secure  and  maintainable  software  product. 

o  Make  extensive  use  of:  exception  handling  and  apply  it 
throughout  the  software  system  to  ensure  a  stable  and 
controlled  software  environment. 

o  Be  a ware  ot  which  Ada  compiler  you  are  using,  and  make 
sure  you  keep  current  as  improved  and  validated 
versions  become  ecu  l  iable. 
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